This page walks you through the 15 questions you'll be asked, with a short brief and useful context for each. Use it to read ahead, take notes as we talk, or both — your notes save automatically to this browser only.
An EMBA Applied Research Project at SP Jain. The paper proposes a framework called ABSD for how AI systems can understand why users behave the way they do — not just what they do.
The framework is grounded in research but needs people who actually build AI products to pressure-test it. Your domain knowledge and instincts about user behaviour are what we want to surface.
No question has a right answer. We're interested in how you actually think about user behaviour in your work — patterns you've noticed, things that surprise you, intuitions you couldn't fully defend. Skip anything that doesn't apply.
Just an orientation. We want to know your role, what kind of AI system or product you work on, and roughly the kind of users it serves.
This is the baseline. What kind of data does the system actually collect, and what does it do in response? Stay descriptive — no need to defend the design.
Most systems today operate at the Action layer — they log events and respond to them. The paper argues this leaves three deeper layers (Behaviour, State, Drive) largely unaddressed.
We're trying to surface the signals you have learned to read — whether or not they're tracked formally. The thing you notice in user-session replays. The pattern that makes you say "something's wrong here."
You may have others not on this list — that's exactly what we want.
Especially: hesitation, navigation switching, re-engagement after drop-off, help-seeking, or changes in interaction pace.
Two parts: what you actively track today, and what's sitting in your event logs that nobody has looked at yet. The gap between "available" and "used" is often where the most interesting questions live.
Forrester (2022) found 73% of companies struggle to use behavioural data for anything beyond basic segmentation. We want to test whether that matches what you see, and what's blocking deeper use.
The same pause can mean different things — confusion, deliberation, distraction, cognitive load. We want to know how you read it in your specific domain, and how much you'd bet on that reading.
A 30-second pause before a complex financial trade is prudent deliberation. The same pause before a simple checkout is probably confusion.
Same signal, different state — because context changes everything.
Genuinely — does this structure feel natural, or does it impose distinctions that aren't useful in practice? We're looking for friction as much as agreement.
Action generates trace data. Behaviour is the pattern in that trace. State is what the user is feeling. Drive is the deeper need shaping how they react to challenge. Each layer is generated by the one above (from the user's side) and must be inferred from the one below (from the AI's side).
Two short stories. The clean read — and the time you got it wrong, or couldn't tell. The ambiguity is often more revealing than the certainty.
In the paper this is called context-dependent signal interpretation. Narayanan & Georgiou (2013) described behavioural signals as having "individual and contextual heterogeneity" — they refuse to be deterministic.
What changes the meaning of the same behavioural signal? Domain? User history? Time of day? Task complexity? The thing that, when you check it, reframes everything.
If you'd add a fourth category, that's exactly the kind of input we need.
What's the feedback loop between inference and ground truth in your system? Surveys? Support tickets? Conversion outcomes? Just a hunch?
The paper argues that state-aware systems risk operating in a closed inferential loop — unchecked assumptions compounding over time. Whatever you do to break that loop is what we want to learn from.
This is the deepest layer — Drive. Does your product try to support these needs, even implicitly? Or does the conversation never get there?
Autonomy — feeling in control of your choices. Competence — feeling effective at what you're doing. Relatedness — feeling connected to others.
Forty years of research show these predict engagement and wellbeing across domains.
The hypothetical world where the system actually knows the user is confused, or frustrated, or in flow — what would it do differently?
The honest reasons it hasn't happened. Technical? Data? Organisational? Ethical? Just no-one's prioritised it?
This is the utility test. The framework isn't trying to be novel — it's trying to be useful. If the layer-language gives you something to point at in meetings, it earns its place. If not, it's just clever.
Imagine your next product review. Someone says "users are dropping off after onboarding." With ABSD vocabulary, would you reframe the conversation differently?
This is the most valuable question in the whole interview. The framework will only be useful if practitioners shape it. What does it not yet cover that it should? Where does it overclaim? What feels missing?
If a system in your space genuinely understood why users were doing what they're doing — where would that change the most? One use case, sharply drawn.
This question turns the whole interview forward. We're trying to find the highest-leverage applications of the framework, and you've just spent 15 minutes thinking about where the gaps are.
The framework only sharpens when practitioners push on it. Your notes are saved in this browser. If you'd like to share them with the researcher, export below.
Notes never leave your browser unless you choose to share them.